Access rights workflow for accounts, groups, and roles

The SessionM Platform means little without its users! Setting up users on the platform is a process that touches three distinct parts of the Admin & Rights Module: Accounts, Groups, and Roles. While these three kinds of objects appear to be separate, they do, in fact, function together. In short, a user account can be part of a group, which is itself defined by roles - each role containing rules that specify the actions users can take within a specific module. Objects defined in each part of the system ensure that the account hierarchy you design is both logical and flexible.

For basic information on the UIs supporting accounts, groups, and roles, see About Accounts, Groups, and Roles.

Access rights

Before you begin, you might consider that the heart of your user account hierarchy are access rights. It's recommended that all user accounts are created in accord with whatever access rights you define for the organization. These rights can reflect how you expect users to work within the platform. For example, one set of access rights might be designed for those users tasked with building campaigns. In order for them to do their work, they need to create, read, and update campaigns. Another set of access rights might be designed to reflect the responsibilities associated with users that manage the people building campaigns; so they need the same access rights plus additional ones that allow them to approve or delete campaigns.

Access rights can be designed and implemented two ways:

  • With groups and roles, which define the actions allowed on specific kinds of data within platform modules.
  • Individually, with user accounts, which specify levels of access (read, write, approve, publish) for specific modules or parts of modules.

Note that group permissions are added to any permissions individually set for the user, so you can use both approaches discussed below for setting up account access.

Via groups and roles

In this approach, groups and roles can have very granular access rights to types of data within modules based on actions, including:

  • Actions that "get" and "list" data. No ability to change data.
  • Actions that "create," "update," and "delete" data.

  • Actions for administrative abilities such as those that pertain to campaigns ("approve," "start," "suspend") or to customers ("sync," "update_status," "reset sms verification," "reset_password").

Via individual accounts

In this approach, individual user accounts can have a combination of access rights to platform modules or parts of modules, including:

  • Read – Platform user is able to view the applicable module but cannot make any changes to data in the module.
  • Read & Write – Platform user is able to both read and make changes to data in the applicable module.
  • Approve & Publish – In modules where marketing content is created, an additional level of access is required to approve and publish created content.

Once configured, individual permissions appear as checked boxes on a user account details page.

Workflows to configure access rights

Of course there are a variety of ways to configure accounts, groups, and roles in support of an access rights scheme. Here are a few approaches that are both typical and recommended:

Scenario 1: Create roles and accounts for assignment to groups

This is the workflow for this scenario:

  1. Create roles that define allowable actions (e.g., list, create, delete) for specific types of data (e.g., customer profiles or event streams)
  2. Create accounts.
  3. Create groups that combine roles and user accounts.

Advantages of this approach:

  • Resources in roles support granular allocation of access.
  • Good for established SessionM implementations that already contain multiple users.
  • Easy to add accounts and roles to groups when creating groups.
  • All user accounts in groups inherit same access rights to platform, making it easy to manage large groups of users.

Scenario 2: Create roles for empty groups and assign accounts

This is the workflow for this scenario:

  1. Create roles that define allowable actions (e.g., list, create, delete) for specific types of data (e.g., customer profiles or event streams).
  2. Create groups with roles but without user accounts.
  3. Add user accounts that get assigned to groups when the accounts are created.

Advantages of this approach:

  • Resources in roles support granular allocation of access.
  • Good for new SessionM implementations that contain no users.
  • Easy to assign accounts to groups as you create the user accounts.
  • All user accounts in groups inherit same access rights to platform, making it easy to manage large groups of users.

Scenario 3: Create accounts and assign access rights manually

This is the workflow for this scenario:

  1. Create accounts, manually defining access rights to each desired module.

Advantages of this approach:

  • No need to create roles or groups.
  • Can create custom, granular access right assignments for each user.